Mining the Electronic Health Record

How many researchers…?

image of a light bulb

The best thing about being a statistician…

John Tukey

Backyard #1

Children's Mercy Hospital building

Backyard #2

Cleveland Chiropractic College building

Backyard #3

MRI Global building

Backyard #4

North Kansas City Hospital building

Backyard #5

Saint Luke's Hospital building

Backyard #6

Truman Medical Center building

My favorite two backyards

UMKC and KUMC mascots

New backyard: Russ Waitman

Russ Waitman

i2b2 software

Screenshot of i2b2 software

The common standard for research using the electronic health record is i2b2.

It's an open standard which should be attractive to anyone in this audience who is a student. You learn i2b2 here, and everything you learn will transfer directly to the job you get after you graduate.

They are using i2b2 at some of the local playgrounds that I showed earlier: Children's Mercy, Saint Luke's, and Truman Medical Center. But the i2b2 system at KU Med Center is really great. They've included records from both the billing side and the clinical side. How cool is that! They've integrated the electronic health record with a cancer registry and a trauma registry. They have a slick system called data builder, which dumps the i2b2 records into a SQLite database that you can import into R, and they even let mere mortals like me query directly from the actual database.

The i2b2 software is great for targetted research involving a well structured research hypothesis. But for data mining, which is a more unstructured approach, you have to dig a bit deeper.

The database structure behind i2b2

Diagram of i2b2 schema

How many surgeries?

## How many surgeries?

select_surgeries <- 
  "SELECT name_char FROM blueherondata.concept_dimension
     WHERE name_char LIKE '%ectomy%'"     
dbGetQuery(c_connect, select_surgeries) %>%   # Extract records
  use_series(NAME_CHAR) %>%                   # Convert to vector
  strsplit(" ") %>%                           # Split into words
  unlist %>%                                  # Re-convert to vector
  tolower %>%                                 # Force to lower case
  grep("ectomy", ., value=TRUE) %>%           # Toss extraneous words
  gsub("[[:punct:]]", "", .) %>%              # Remove punctuation
  gsub("ectomy.*", "-", .) %>%                # Remove ectomy suffix
  unique %>%                                  # Remove duplicates
  sample(100, replace=FALSE) %>%              # Select 100 random
  sort %>%                                    # Arrange
  paste(collapse=", ")                        # Delimit with commas

How many surgeries?

"acromion-, adenoid-, alveol-, apic-, apico-, arthr-, arytenoid-, astragal-, ather-, burs-, capsul-, carp-, clitor-, coccyg-, crani-, dacryoaden-, dacryocyst-, diaphys-, disarticulationhemipelv-, disk-, diverticul-, endarter-, epididym-, epiglottid-, epiplo-, ethmoid-, fasci-, fistul-, frenul-, ganglion-, gastr-, gingiv-, gloss-, hemigastr-, hemigloss-, hemilamin-, hemilaryng-, hemiphalang-, hemorrhoid-, hepat-, hymen-, hyster-, infundibul-, irid-, labyrinth-, lamin-, lip-, lump-, mucos-, my-, myom-, nephr-, nephroureter-, oophor-, osteophyt-, pannicul-, patell-, phalang-, pharyngolaryng-, phleb-, pleur-, plex-, pneumon-, postadenoid-, postcholecyst-, postgastr-, postlymphaden-, postmastoid-, postpolyp-, postprostat-, postsplen-, prostat-, rectosigmoid-, salping-, salpingoophor-, scler-, segment-, sequestr-, sialoaden-, sigmoid-, sphenoid-, sympath-, synov-, tenon-, tenosynov-, trabecul-, trachel-, trisection-, trisegment-, turbin-, tyl-, tympanomastoid-, umbil-, urethr-, uvul-, vagin-, valv-, vas-, vesicul-, vulv-"

The full list of "ectomies" would be about twice as big. And that illustrates a key challenge with this type of data. It is very sparse. There are hundreds of things that a surgeon can cut out of you, but you should be very grateful that the doctor only chops out one or two things at the most. Looking at the drugs that you could get, even the worst polypharmacy cases would be a small fraction of thousands of drugs that are available. The number of diagnosis codes that you are assigned is also a small fraction of the number of diagnoses that they could hang on you. So the design matrix for any regression model in this area becomes really huge and most of the entries are zeros.

The other thing about the electronic health record is that each operation, each drug, each diagnosis code sits on a separate record. It has to, or the record would string out so long that it would be unmanageable. So you can't say "Give me the record for a patient with sleep apnea getting Propofol anesthetic for a septoplasty." Instead, you have to match the apnea record with the Propofol record with the septoplasty records. This means using a self-join. Self-joins are tricky. They usually require using nested queries and they can be very inefficient.

I don't want to scare you away though. Mining the electronic health records has been one of the most fun backyards I've had a chance to play in.

Mei Liu, Acute Kidney Injury

Mei Liu, next to one of her research publications

<<<<<<< HEAD ======= >>>>>>> 495d4b13430a8f7cba27672caf926040d05f000f

Requirements needed for mining the electronic health record

Technical requirements

Working familiarity with SQL
Data wrangling skills

Non-technical requirements

Lust for data
An interesting backyard

So if you want to work in this area that I call "Mining the electronic health record" you need four things. You need to have a working knowledge of SQL. Not at the level of a database administrator, but you do have to know how to use the WHERE clause, the various types of joins, and a few other basic things. You also have to be pretty good at data wrangling. Data wrangling is a term that some guy (I'm sure it was a guy) developed to make the term data management sound more macho.

More important than these technical skills is that you have to get excited about data. If you weren't salivating at the code that pulled every whatever-ectomy out of the database, then maybe this isn't for you. The final requirement, though, and one that I am sure you already have, is an interesting backyard. I'm not a doctor, and all the examples I come up with on my own for mining the electronic health record are pretty trivial from a medical perspective. If you can bring me an interesting medical question, I can help you with the SQL and the data wrangling.

Informatics meetup

Flier for May 23 Informatics meetup

Where you can find a copy of this talk.

This presentation was developed using R Markdown. You can find all the important stuff at

https://github.com/kumc-bmi/heron-i2b2-analytics

In particular, look for

doc/mining-v2-image-credits.txt
doc/mining-v2-slides.pptx
doc/mining-v2-speaker-notes.pdf

=======

"An electronic health record (EHR) is a digital version of a patient’s paper chart. EHRs are real-time, patient-centered records that make information available instantly and securely to authorized users." (healthit.gov)

>>>>>>> 495d4b13430a8f7cba27672caf926040d05f000f